home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000011_owner-urn-ietf _Mon Nov 4 01:02:01 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA25122 for urn-ietf-out; Mon, 4 Nov 1996 01:02:01 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA25117 for <urn-ietf@services.bunyip.com>; Mon, 4 Nov 1996 01:01:58 -0500
  3. Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA20136  (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 01:01:46 -0500
  5. Received: from nic.cafax.se (paf@nic.cafax.se [193.12.122.42])
  6.         by nic.cafax.se (8.8.2/8.8.2) with SMTP
  7.         id HAA03068;
  8.         Mon, 4 Nov 1996 07:01:26 +0100 (MET)
  9. Date: Mon, 4 Nov 1996 07:01:25 +0100 (MET)
  10. From: Patrik Faltstrom <paf@swip.net>
  11. X-Sender: paf@nic.cafax.se
  12. To: "Gregory J. Woodhouse" <gjw@wnetc.com>
  13. Cc: Leslie Daigle <leslie@bunyip.com>,
  14.         Daniel LaLiberte <liberte@ncsa.uiuc.edu>,
  15.         "Karen R. Sollins" <sollins@LCS.MIT.EDU>, urn-ietf@bunyip.com
  16. Subject: Re: [URN] some comments
  17. In-Reply-To: <Pine.SGI.3.95.961103181127.6436A-100000@shellx.best.com>
  18. Message-Id: <Pine.BSI.3.91.961104065610.3061A-100000@nic.cafax.se>
  19. Mime-Version: 1.0
  20. Content-Type: TEXT/PLAIN; charset=US-ASCII
  21. Sender: owner-urn-ietf@services.bunyip.com
  22. Precedence: bulk
  23. Reply-To: Patrik Faltstrom <paf@swip.net>
  24. Errors-To: owner-urn-ietf@bunyip.com
  25.  
  26. On Sun, 3 Nov 1996, Gregory J. Woodhouse wrote:
  27. > 
  28. > Look at it from the point of view of implementation: Is
  29. > http://foo.bar.com/ a URL or a URN? 
  30.  
  31.    http://foo.bar.com/      is a URL
  32.    urn:http://foo.bar.com/  is a URN
  33.  
  34. > Is there any conceptual reason why
  35. > http: cannot be a valid URN scheme? If it is possible for this to be a URN,
  36. > then under the NAPTR proposal it would be first necessary to do a DNS query
  37. > and receive and address for a service which will either resolve it for us
  38. > or tell us that it corresponds to the URL http://foo.bar.com/. Armed with
  39. > the information that this latter URI is a URL it is then possible to use
  40. > HTTP to retrieve the resource.
  41.  
  42. >From an implementation standpoint the big difference is that when you
  43. have a URN scheme, the resolution protocol have to be able to
  44. change over time (in the NAPTR proposal from DNS to something else),
  45. the protocol used to fetch the data have to be able to be different
  46. between different locations of the resource (see the NAPTR and SRV
  47. records the NAPTR proposal uses) and the namespace have to be able
  48. to both grandfather and be grandfathered later on. All of the above
  49. without changing the name.
  50.  
  51. One of the methods of doing a N2R, N2L, N2C etc. fetch for a
  52. URN after resolution is to use the http URL scheme, but that
  53. is definitely _after_ all of the URN abstraction levels have been
  54. resolved.
  55.  
  56.     Patrik
  57.